IBIS Macromodel Task Group Meeting date: 25 June 2013 Members (asterisk for those attending): Agilent: * Fangyi Rao * Radek Biernacki Altera: * David Banas Julia Liu Hazlina Ramly Andrew Joy Consulting: Andy Joy ANSYS: Samuel Mertens * Dan Dvorscak * Curtis Clark Steve Pytel Luis Armenta Arrow Electronics: Ian Dodd Cadence Design Systems: Terry Jernberg * Ambrish Varma Feras Al-Hawari Brad Brim * Kumar Keshavan Ken Willis Cavium Networks: Johann Nittmann Celsionix: Kellee Crisafulli Cisco Systems: Ashwin Vasudevan Syed Huq Ericsson: Anders Ekholm IBM: Greg Edlund Intel: Michael Mirmak Maxim Integrated Products: Mahbubul Bari * Hassan Rafat Ron Olisar Mentor Graphics: * John Angulo Zhen Mu * Arpad Muranyi Vladimir Dmitriev-Zdorov Micron Technology: Randy Wolff Justin Butterfield NetLogic Microsystems: Ryan Couts Nokia-Siemens Networks: Eckhard Lenski QLogic Corp. James Zhou SiSoft: * Walter Katz * Todd Westerhoff Doug Burns Mike LaBonte Snowbush IP: Marcus Van Ierssel ST Micro: Syed Sadeghi Teraspeed Consulting Group: Scott McMorrow * Bob Ross TI: Casey Morrison Alfred Chong Vitesse Semiconductor: Eric Sweetman Xilinx: Mustansir Fanaswalla Ray Anderson The meeting was led by Arpad Muranyi ------------------------------------------------------------------------ Opens: - Need a volunteer to take minutes, Curtis to take the minutes. - Meeting will be held as scheduled on July 2, 2013. -------------------------- Call for patent disclosure: - None ------------- Review of ARs: - Ambrish update BIRD 147 - Ambrish ready to present changes made in response to previous meeting. ------------- New Discussion: Interconnect update: - Walter: I gave a presentation regarding EMD, package, On Die Interconnect. - Do we handle On Die with BIRD 145 [Model Call] or new EMD methodology? BIRD 155, New AMI API to Resolve Dependent Model Parameter: - Fangyi: (presenting the latest BIRD draft) - Radek and I modified this and included input from Walter. - Shortened the name of one API function to AMI_Resolve(). - Added AMI_Resolve_Close(char * AMI_parameters_out); - Purpose is resource cleanup. - Previously, AMI_Init() was going to handle this cleanup. - Walter suggested decoupling "Resolve" from other AMI functions. - Arpad: That's a good idea [decoupling them] - ex. With BIRD 160 you might have a .dll with only Resolve functionality. - Kumar: You would then make AMI_Init() and AMI_Close() optional. - Todd: What would we need this for without having an AMI_Init()? - Arpad: With BIRD 160 you might have dependent analog parameters but no AMI. - Radek: But we currently point to the .dll with the [Algorithmic Model] line. - Todd: Resolve without Init is a solution in search of a problem. - Fangyi: I agree, it is likely tied to AMI. - Walter: One possibility - separate .dll for the Resolve functions. - Radek: Todd is right, let's stick to AMI use of Resolve for now. - Fangyi: (resuming review of BIRD draft) - Resolve_Close() is required if the parameter Resolve_Exists is true. - (described the usage flow of the Resolve API (steps 1 through 9)) - Todd: If Resolve_Exists is true, what do you pass in? The whole tree? - Fangyi: No, only parameters of type "In" [step 4. in flow] - Fangyi: We introduce a new usage "Dep". - If a parameter is updated by AMI_Resolve(), its usage is "Dep". - If a parameter is updated by AMI_Init(), its usage is "Out" or "InOut". - A list of parameters that can not have usage "Dep" is provided. - Kumar: I don't think we need Resolve_Exists. The tool can figure it out. - Fangyi: Yes, the tool could look for the entry point. - But this is consistent with GetWave_Exists. - From past discussions, justifications include a model developer who wants to include a function (debug) but doesn't want it used. - Kumar: So the parameter has priority. - The tool uses Resolve_Exists and ignores Resolve functions if it is false. - Fangyi: Yes, it says that in the flow. - Todd: Could I step back and look at the big picture? - SiSoft approach was to handle these dependency issues without .dll change. - This is effectively passing a table to a new entry point in the .dll. - Fangyi: Yes, I think this approach is extremely flexible. - Todd: You call AMI_Resolve() and then pass the entire reply to AMI_Init()? - Fangyi: No "Dep" parameters don't go to AMI_Init(). - The purpose of AMI_Resolve() is to get the dependent parameters needed to calculate the impulse response of your circuit. - You need resolution of these before AMI_Init() because it's too late then. - Todd: Ah, I understand. - Walter: ex. Tstone_file becomes "Dep" not "Info" - Jitter params in IBIS 6.0 are all "Info". Must they now become "Dep"? - Fangyi: AMI_Init() could choose TxRj using the same method as AMI_Resolve(). - Walter: No, the .dll doesn't use TxRj. - Fangyi: Oh, right. Yes, we have to allow TxRj to be "Dep" as well as "Info". - Radek: If AMI_Init() needs a dependent value it can calculate it the same way. - Walter: I sent an email today regarding a new leaf on usage. - Fangyi: Can we finish this discussion first? - John: Why do we need "Dep" at all? - Fangyi: "Dep" prevents the possibility of something being updated twice. - Radek: The old "Out" becomes complementary subsets "Out" and "Dep". - John: The tool could detect that something had been updated twice. - Radek: And then what...? - Fangyi: It forces the model maker to specify. - Kumar: I like "Dep" to make it clean. - Radek: Table 17 lists the Usage type allowed for various Reserved parameters. - Extend this table so "Dep" is an option. - John: Were the original analog parameters (load, etc.) all "Info"? - Arpad: They were Reserved parameters only. - Tool wouldn't know what to do with Model Specific parameters. - Now with BIRD 160, Model Specific Info params used by [External Model]. - Walter: The model user first has to make various parameter value selections. - Input to Resolve function is "Info". - Output of Resolve is classic "Info" parameters. - We need to know which are "Dep-In" and which are "Dep-Out". Which are which? - Overloading Usage with "Dep" is a confusing way to handle it. - Fangyi: You're moving on to your topic now... - Ambrish: Could I suggest that we see some implementations of old examples? - Fangyi: Okay, we will create one. - Arpad: Is this BIRD to exist in parallel with BIRD 150 or to replace it? - Ambrish: We should pick one or the other. - Arpad: Yes, I would also prefer one or the other. Perhaps this one. - Bob: I have some Table 17 comments. - We've deprecated "Out" for some Reserved Parameters. - Almost all Reserved Parameters are "Info". - Radek: Reserved "Info" parameters can be returned by AMI_Init(). - Walter: There are plenty of BIRD 150 examples. - In some of them the inputs to the AMI_Init() function are resolved. - Fangyi: If you're using a dependency table to resolve an input, then the same resolution could just be done inside the AMI_Init() call. - Arpad: Looking at the clock, should we now move over to Ambrish's update? Bird 147 - Back-channel Support: - Ambrish: (showing latest changes based on the last meeting) - Tree root name "BCI". - States that the parameter string is constructed according to existing rules. - States how to resolve Training Bits vs. Ignore bits values. - Todd: BCI file defines allowed messages that can be passed from Tx to Rx? - Bob: BCI root name is for protocol specific parameters only? - Ambrish: Any InOut parameter in the BCI goes back and forth from Tx to Rx? - Todd: Reiterate that this defines legal messages and values. - Walter: Yes, in a separate tree. - Ambrish: A separate "BCI" root. - Bob: This is not a root, it's under "Protocol Specific". - Arpad: Isn't "Protocol Specific" too generic? - This is a training protocol? What if there are others? - Ambrish: BCI is for training. - Arpad: Now is a good time to stop. See you all next week. ------------- Next meeting: 02 July 2013 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives